Tech

Diary

Lecture

About Me

개발중

블랙, 화이트 박스 테스팅

JeongSeulho

2023년 05월 09일

준비중...
클립보드로 복사

📌블랙 박스 테스트

  • 소프트웨어의 명세에 기반하여 테스트(코드를 직접 보지 않음)
  • 명세서의 기능들을 동작하도록 테스트하는 것이 목적
  • 명세에 없는 세부적인 오류는 찾기 힘듬

📖장점

  • 도메인에 집중할 수 있다
  • 코드가 필요 없다, test case 디자인을 미리 할 수 있다
  • 명세에서의 논리적 오류를 찾을 수 있다
  • 유닛 테스트나 통합 테스트 모두 적용 가능

📖과정

  1. 테스트 가능한 특징들을 뽑아낸다

  2. 해당 특징들의 입력들을 선별

  • 입력 요소가 3가지에 각각 정상 3가지/비정상3가지/예외2가지 총 조합의 수 = 18가지
  1. 입력들의 조합으로 test case 명세서를 만든다
  • 18가지 조합의 수 test case
  1. 명세를 기반으로 구체적인 test case 만든다

📖create/select test case

  • Equivalence class partitioning : test case에 그룹을 나누고 각 그룹의 하나의 케이스만 뽑아낸다, example) 1~100의 input 테스트시 1~50의 그룹1 / 51~100그룹2로 나누고 각 그룹의 대표하는 한가지 case만 추출하여 실제 테스트
  • Boundary value analysis : 위에서 정한 그룹의 경계 데이터(1, 49, 52, 99 등)만 뽑아서 테스트
  • Model-based testing : state diagram에서 모든 state를 커버하도록 테스트하는 것(이것도 그룹을 나누어서 대표 case를 하나 선별하는 것과 비슷한 느낌)

📖test case 조합 사이트

  • 굉장히 다양한 조합 경우의 수의 케이스를 생성, 관리하는 툴
  • www.pairwise.org / PICT / TSL generator

📌화이트 박스 테스트

  • 코드를 직접 보고 코드 기반으로 테스트
  • 코드에 구현된 것들을 동작하도록 테스트하는 것이 목적

📖장점

  • test suites(테스트 그룹)를 비교가능 : A테스트그룹이 B테스트그룹을 포함하면서 비용이 비슷하다면? A테스트그룹만 선택함, 이러한 비교가 가능
  • 객관적으로 테스트 결과를 확인할 수 있고 자동화 테스트가 가능

📖control flow graph

  • 프로그램 제어 흐름을 그래프로 그려서 이 그래프를 커버하도록 테스트 케이스를 설계하는 방법이 존재
  • basic path : 시작노드부터 끝노드까지 순회하는 각 경로를 지칭
  • cyclomatic complexity : 독립적인 basic path의 개수로 계산하는 복잡도
  • 모든 basic path를 커버하는 테스트 케이스를 설계하는 방법
  • 4가지 basic path가 존재

📖Test Coverage

  • basic path coverage : test suites(tc1, tc2, tc3 …)가 basic path를 모두 cover할 때
  • all path coverage : test suites(tc1, tc2, tc3 …)가 모든 path 조합을 cover할 때
  • statement, branch, condition, multiple condition, MC/DC 등등 존재
  • 이러한 test suites들을 서로 포함 관계로 비교가 가능한 것이 특징

✒️statement Coverage

  • 모든 코드를 적어도 한번씩 실행하여 cover하는 test suit
  • 밑 예에서 TC2는 statement coverage

✒️branch Coverage

  • 모든 branch(edge)를 cover하는 테스트 범위
  • 밑의 예에서 F-F branch를 커버 + T-T branch를 커버하는 test suit가 branch Coverage

✒️condition Coverage

  • 작은 단위의 조건문 까지 모두 cover하는 test suit
  • 각 조건문의 T,F를 모두 테스트

✒️branch vs condition

✒️multiple-condition coverage

  • 목표 : condition과 branch를 모두 만족하는 test case 디자인하기 방법1
  • 각 조건에대한 모든 경우의 수 test suit, 조건이 n개 있으면 2^n만큼의 경우의 수가 생김
  • 너무 많은 test case

✒️MC/DC coverage

  • modified condition, decision coverage
  • 목표 : condition과 branch를 모두 만족하는 test case 디자인하기 방법2

    MC/DC pair의 개념 if(A and B and C) { … } 코드 존재, TC1 : (A,B,C) = (T,T,T) -> outcome=T TC2 : (A,B,C) = (T,T,F) -> outcome=F C만 바꿨는데 결과가 바뀌었으므로, C가 결과에 영향을 미침 TC1 와 TC2를 MC/DC pair라 지칭한다

  • MC/DC coverage는 이러한 MC/DC pair들을 모두 모아둔 것
  • 위에서 C에대해서 MC/DC pair인데 A에대해서, B에대해서 모두 test case를 디자인하면 그것을 MC/DC coverage test suite라 한다
  • TC1-TC2 / TC1-TC3 / TC1-TC5 라는 MC/DC pair로 MC/DC coverage 만족 최종 test suit = {TC1, TC2, TC3, TC5}

📖Test Coverage 포함 관계 비교

  • 큰 원의 test suit를 테스트 했다면, 그에 포함되는 내부의 test suit를 테스트 할 필요는 없음

📌test trend

  • 개발자가 직접 본인의 코드를 test하는게 일반적
  • TDD 시행
  • 테스트 자동화
CS